home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0032-Re Comparing Object-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  3.9 KB  |  79 lines  |  [TEXT/GEOL]
  1. Item    2273449                         12-June-89        13:14
  2.  
  3. From:   ALGER                           Alger, Jeff
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Re - Comparing Objects
  8.  
  9. Alan, Chuck, Keith, et al,
  10.  
  11. Add my vote to those asking for TObject.Compare and TObject.IsSame. I agree
  12. with Chuck Lins that identity should be separated from ordering by having a
  13. distinct IsSame method.  Ordering is (usually) a property of the set, rather
  14. than the class (although more about that later,) while identity is a property
  15. of the class.
  16.  
  17. Some careful attention to semantics is required in order to make a
  18. TObject.IsSame method useful and meaningful.  In particular, it is important to
  19. preserve reflexivity and transitivity in an IsSame method.  Suppose we have
  20. three objects x, y, and z of classes A, B, and C, respectively.  Reflexivity
  21. should guarantee that when x.IsSame(y) is true, y.IsSame(x) is true.
  22. Unfortunately, this is not always possible to guarantee.  If B is a subclass of
  23. A which overrides IsSame, reflexivity in this strict sense is not guaranteed.
  24.  
  25. However, if you interpret things a little different, reflexivity holds.
  26. Interpret x.IsSame(y) as follows:
  27.  
  28. 1. If class B is the same as class A, x.IsSame(y) must implemented to be
  29. reflexive and transitive.
  30. 2. If class B does not have class A as an ancestor, x.IsSame(y) is undefined.
  31. 3. If class B does have class A as an ancestor, x.IsSame(y) is equivalent to
  32. x.IsSame(A(y)).
  33.  
  34. This means that reflexivity is always guaranteed whenever IsSame is
  35. well-defined.  As to transivitity, x.IsSame(y) and y.IsSame(z) clearly need not
  36. imply x.IsSame(z), but x.IsSame(A(y)) and A(y).IsSame(A(z)) just as clearly
  37. will imply x.IsSame(A(z)).  The bottom line is that reflexivity and
  38. transitivity are preserved as long as all of the objects under discussion are
  39. coerced to a common class before applying the IsSame method.
  40.  
  41. As to ordering, a set can be unordered, partially ordered, or fully ordered.
  42. An unordered set, such as a hash table, does not support the notion of a
  43. successor or predecessor to a given object, while an ordered set does.  In a
  44. partially ordered set, there may be non-unique keys, which is to say, two
  45. distinct objects may compare as “equal” for purposes of set ordering, while in
  46. a fully ordered set two objects can compare as “equal” only if they are the
  47. same object.  One object can be an element of any number of sets, each of which
  48. may have its own definition of “order” or no order at all.
  49.  
  50. On the surface, this argues for keeping IsSame in TObject, but Compare as a
  51. method of the set.  However, in practice there are many object classes which
  52. have an obvious natural ordering.  In such cases, it makes sense to provide a
  53. Compare method for the element class, rather than the set.
  54.  
  55. I see no reason to avoid a TObject.Compare method just because it will not
  56. always be used.  As has been pointed out, one of the few tools available to
  57. deal with the lack of multiple inheritance in Object Pascal is a rich set of
  58. primitive methods of TObject.  It costs next to nothing to provide an
  59. overridable TObject.Compare and it is, at times, useful and meaningful, so why
  60. not?  TObject.Compare does not rule out set-specific ordering.  It is usually
  61. applicable in the simpler cases, and where it does apply one avoids an entire
  62. new class (e.g., a subclass of TSortedList) just to implement a simple sorted
  63. set.  Let’s keep simple things simple to implement: that is, after all, the
  64. spirit of MacApp.
  65.  
  66. Both IsSame and Compare should be able to return “kIncomparable”, as Chuck
  67. suggests, whenever class coercion is not possible.  Also, if both are present,
  68. the default implementation of IsSame can compare object handles without running
  69. afoul of Keith’s concern about consistency across invocations of the
  70. application.  Compare should compare only that which is common to TObject:
  71. class ID and object size, both of which are consistent and result in partially
  72. ordered sets.
  73.  
  74. Further thoughts?
  75.  
  76. Jeff Alger
  77. Peat Marwick Main & Co.
  78.  
  79.